feat(services): progressive referral rail and compact result rows (#163) - #1982

Summary

• Re-measured ledger #163 against main before building anything, and most of what the row asks for had already landed. /services?q= already renders the query as the <h1> through SearchResultsHeaderBand, the shortlist bar is already conditional on a non-empty selection, Compare already exists, and the four-card numbered walkthrough is mounted only on /services/[slug] — tests/ui-tools.spec.ts already asserts it is absent from the results route. The current/ baseline screenshot in the comps folder is from 2026-07-31 and no longer reflects main. This PR closes the residual delta to direction B rather than rebuilding what is already there.
• Added ServiceReferralProgress: a one-line Search / Shortlist / Compare / Refer dot rail whose active stage is derived from the existing shortlist state during render. Its accessible name is "Referral progress", deliberately not the "Referral workflow" name the removed walkthrough used, so the existing absence assertion cannot be quietly satisfied by renaming that component back onto this route. "Refer" is never the current stage here; it is reached on the record.
• Compacted the result row by removing the Catchment / Eligibility / Cost strip and the confidence pill. Three truncated fields per row turned a scan of 45 crisis services into clipped prose; the untruncated values are one tap away on the record behind "Review referral", which is where a referral decision is actually made.
• Added a per-row bookmark wired to account favourites, kept visually and semantically distinct from the shortlist: the bookmark persists across sessions, the shortlist is this search's working set and is deliberately not persisted. Its outcome is announced through a visible polite status region, because "Sign in or create an account to save services" is the common outcome for a guest and hiding it would leave the control looking simply broken.
• Moved the shortlist banner below the heading it qualifies.

Deliberately unchanged, and worth stating because the comp disagrees: SearchResultsHeaderBand's count/query weighting. Direction B draws the query dominant and the count small, but that split is a documented contract (docs/search-chrome-behaviour.md, Results band rules 1–2), is shared by twelve modes, and is visual-baselined from this exact route (tests/ui-visual-baseline.spec.ts). The outcome #163 actually asks for — the <h1> is the query, not a match count — holds either way. The comp-vs-contract divergence is being captured as its own ledger row rather than resolved silently inside a services PR. Also unchanged: the Services ModeHome (this row's stop condition) and the filter contract that PR #1878 landed on 2026-08-13.

One deviation from the comp: the shortlist banner keeps "N shortlisted" rather than "N in shortlist". Same meaning, and it avoids churning two source-text assertions for no behavioural gain.

Verification

• npm run verify:pr-local

PR-local verification summary:
- completed: check:runtime, check:installed-lock-parity, format:changed, lint, typecheck, test, build, check:rag:fixtures, check:medication-interactions, check:medication-lexicon-report
- failed: (none)
- not reached: (none)

Focused proof before that gate:

 Test Files  4 passed (4)
      Tests  22 passed (22)

(services-navigator-scope-empty-state.dom.test.tsx, audit-content-services-regressions.test.ts, search-results-band-adoption.test.ts, route-reachability.test.ts — the first two are the ones that pin this file's effect-free contract and its shortlist source text.)

Design-system contract, run because the row markup changed:

Design-system contract passed (734 production files; raw colors 2; literal shadows 0; legacy tap classes 0; edge conflicts 25; 1px shadow spreads 2).

UI verification not run: the container ships chromium-1194 while the lock pins revision 1234, so check:playwright-browser-revision fails closed and no local Playwright run is possible. Pointing PLAYWRIGHT_CHROMIUM_EXECUTABLE_PATH at the stale shell is forbidden by AGENTS.md. Browser proof for the changed journey therefore rests on the CI Production UI job, which runs ui-smoke and ui-tools; both were extended in this PR to assert the new rail's stage progression and the compacted row.

Risk and rollout

• Risk: the row now shows less at a glance — Eligibility and Cost are no longer on the result card. That is the intended direction-B change, and both fields remain on the service record one tap away, but it is the change most worth a second opinion in review. Secondary risk is the bookmark: it writes to account favourites from a results row for the first time, so a save failure or an unauthenticated user must degrade visibly rather than silently, which is why the status region is visible rather than sr-only.
• Rollback: single commit, revertable on its own. Nothing in it is depended on by other work.
• Provider or production effects: None. The bookmark uses the existing /api/account/favourites endpoint already used by the service, form, and differential record pages; no new endpoint, schema, or provider call was introduced.

Clinical Governance Preflight

The classifier returns clinicalRisk: false for these paths, so this section is not required — completed anyway because the change alters which clinical fields a referral result row displays.

• Source-backed claims still require linked source verification before clinical use
• No patient-identifiable document workflow was introduced or expanded without explicit governance approval
• Supabase target remains Clinical KB Database (sjrfecxgysukkwxsowpy)
• Service-role keys and private document access remain server-only
• Demo/synthetic content remains clearly separated from real clinical sources
• Source metadata, review status, and outdated/unknown-source behavior remain conservative
• Deployment classification/TGA SaMD impact was checked when clinical decision-support behavior changed

On the row-content change specifically: no service data, ranking, or source governance behaviour changed. Only which already-public fields the results row surfaces changed, and the removed fields remain reachable, untruncated, on the record.

Notes

• RAG impact: no retrieval behaviour change — this PR touches only the services results presentation layer (services-navigator-page.tsxrendering and its tests). Retrieval, ranking, selection, and scoring are untouched;rankServiceRecords, the facet/scope pipeline, and relevanceRankMap` are all called exactly as before.
• While running the design-system contract I found a pre-existing baseline drift unrelated to this change: legacyShadowAliases measures 118 on clean origin/main while scripts/design-system-contract-baseline.json pins 119. Verified by running the checker against the unmodified file. That is one unit of stale ratchet slack and belongs to the gate work in ledger #265, not here.

Generated by Claude Code